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I am particularly pleased to have been invited to 
address this third annual N. M. A. A. Electronic Busi- 
ness Systems Conference. I was privileged to speak at 
your last conference in San Francisco—and when it was 
all over, I thought of many things I would like to have 
included and a few I might well have left unsaid. 
Either these weaknesses went undetected or your pro- 
gtam committee graciously overlooked them—in any 
event, I’m back again and happily so. The reasons I’m 
so pleased to be with you again are twofold: (1) I feel 
a sort of mission in life to spread the gospel, as it were, 


and I think this particular organization is a most fertile 
field from which to recruit computer operating and 
programming personnel. (2) The second reason is that 
we at Argonaut have survived some enlightening and 
sometimes harrowing experiences in the last 12 months 
and I think that a frank discussion of these experiences 
can be of some real value to you as users or potential 
users of Electronic Data Processing equipment. 


Before such a discussion can be intelligently under- 
taken, I should relate some pertinent information about 
Argonaut operations. 


PP 5 & 6 S. R. I. Report “Workmen’s Compensation 
Insurance (including figures). 


One of the most interesting aspects of Argonaut is 
its size; comparatively speaking it’s small—but grow- 
ing. Our premium volume (or income) for 1955 was 
16,512,000; for 1956, 17,109,000. The corresponding 
policy count for these years was 1955, 20,689; 1956, 
18,955. As you can see, the net effect of this increase in 
premium and decrease in policy count is to raise the 
average value of each policy. Another revealing bit of 
Statistics is the relationship between the number of 
employees and the premium volume, a relationship we 
call ‘dollar value per employee.” In 1955 this figure 
was 66,000 dollars; in 1956, 74,000 dollars. 


I cite these few statistics to illustrate the quest, in 
all business, for economy of operation—a quest which, 
I am happy to state, has been at least partially success- 
ful at Argonaut. We recognized some years ago, how- 
ever, that if we were to maintain our competitive posi- 
tion, we must investigate the potential of computing 
machinery, with its possibilities of savings even greater 
than those offered by punched card systems. 


With this background in mind, let’s pause a moment 
and contemplate what I feel is a fairly profound and 
sage observation (not my own, I must admit). “It’s 
what you learn after you think you know it all that 
really counts.” Doing a little honest soul-searching, 
we, at Argonaut, must admit that this is just about our 
true position at this time. We have taken the big 
plunge—purchased and installed equipment that, when 
properly handled and used, spells out the magic phrase, 
“integrated electronic data processing.” What have we 
done with it and what have we learned from our ex- 
periences? Would we proceed in the same manner if we 
could retrace our steps? These questions constitute the 
theme of this paper and I shall proceed on this basis. 


The first item for consideration in our retrospective 
mood is the question of consultants. I’m sure you have 
all listened to the pros and cons of this issue. In very 
few instances, however, have I heard valid and logical 
arguments in support of a position. In the case of 
Argonaut, there did not seem to be any alternative. We 
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had an interest, but an impressive lack of know-how 
where computers were concerned. We felt that we 
couldn’t even intelligently investigate the situation 
without some help. Therefore, we contracted with 
S:anford Research Institute for a feasibility study. The 
results of this study were published as a report and in- 
dicated clearly that electronic data processing equip- 
ment was within the economic realm of possibility for 
Argonaut. There were two restrictions, however; (1) 
this equipment must be in the medium-size category 
(implying also, medium speed and medium price), and 
(2) this equipment must be used as the information 
processing center of a truly integrated data processing 
system embodying all major jobs that were being done 
on punched card equipment and some that were being 
manually performed. A critical analysis of these find- 
ings revealed no faults or errors, so we proceeded on 
this basis. The next logical step, as suggested in this 
feasibility report, was to request proposals from manu- 
facturers of this “medium” equipment. Never having 
been accused of being kind to manufacturers or their 
sales representatives, I shall not mar my reputation 
now, but will rather proceed with the full explanation 
of this phase of the project. Requests for proposals 
were sent to five manufacturers: IBM, Electrodata, 
Remington-Rand, Underwood, and Marchant. All 
manufacturers replied with proposals. 

Thus began the period of evaluation; determination 
of a course of best action and alternative action. IBM’s 
650 with tapes was almost immediately ruled out, be- 
cause at that time it was available only on a lease basis 
and we felt our best course was to purchase. Incidental- 
ly, the current purchase price of the proposed 650 
system is also prohibitive for us. Remington-Rand’s 
File-Computer system was dropped from consideration 
because of cost. Datatron, Elecom, and Miniac all seem- 
ed to meet all of our requirements. Why did we choose 
Datatron? If we could make the choice again, would 
it be the same? In retrospect, it may seem somewhat 
ridiculous to ask these questions, but, of course, at the 
time, the decision was one of some moment to us. As 
you know, the Underwood Elecom died a quiet death 
with no headlines—the Marchant Miniac is anybody’s 
guess—while on the other side, the success of Datatron 
is well-known to all of you. For those of you who have 
a mind for such things, the real answer to how we hap- 
pened to make a good decision in this case is found in 
Vol. 4, No. 3 of Operations Research under the title 
“Note on Selection of Capital Equipment with Uncer- 
tain Delivery Date.” Incidentally, the author of the 
article is one of our consultants. Thus far we have built 
a fairly strong case for consultants, and we most cer- 
tainly count as one of our most intelligent actions, the 
contract we made to obtain consulting aid. We were so 
pleased, in fact; that when we placed an order for 
equipment, we extended our consulting contract to in- 
clude the system planning and programming phase of 
our project. 

Now the real fun began. The ir formation system at 


Argonaut was classified by major job types as follows: 


I. New and renewal policy writing 
IJ. Payroll Audit 
III. Collections 
IV. Claims 
V. Dividends 
VI. Policy Expiration and Rating Bureau Reports 


VII. Reports to management and governing bodies 
Obviously, this fully integrated system approach was 
going to require a fairly good-sized staff of highly 
competent people if programs were to be written for all 
of these jobs in a year’s time. Management was quickly 
and easily convinced and assigned a total of eight per- 
sons to begin this somewhat monumental task. With 
one exception, these persons were drawn from within 
our own ranks. The single exception is worthy of men- 
tion. The man assigned by ElectroData to write and 
present their proposal, did such an outstanding job that 
we hired him. While manufacturers may frown on such 
action, I recommend it to equipment buyers or lessors. 


After two or three months, however, the urgency of 
the situation seemed to lose its ranking in the minds of 
those responsible for assignment of personnel and our 
staff was gradually depleted as various persons were 
withdrawn and reassigned so as to make more immedi- 
ately effective use of their skills. This in itself was not 
so bad. As most of you know so well, business com- 
petition, just as a military battle, presents situations that 
simply must be met, boldly and quickly, with good per- 
sonnel. Our programming and system planning group 
amounted to a personnel pool of high quality and was 
thus a natural place to turn. We made two serious 
errors during this early programming period. Our first 
was the assumption that we could include not only our 
tabulating department supervisor but his assistant in the 
programming group without having a well-qualified 
man to take over the tab dept. We thought that these 
two could do some part-time long-distance supervising 
and found out that it just would not work. Just about 
the time we realized this obvious truth, the supervisor 
left us for other employment. Of course, we rushed the 
former assistant supervisor back to take active charge of 
the tab. dept., but he’s still trying to put the pieces 
together. 

Our second error of that period was not taking im- 
mediate steps to replace personnel as they were plucked 
away from our group. The situation was deceiving—the 
kind of thing that can so easily happen to a first-timer. 
As these persons were removed from our group, the rest 
of us reviewed progress and work schedules and, with 
blissful ignorance, unanimously agreed “all is well.” In 
reality, however, as we were later to discover, it was 
only “well” on the surface. It was indeed well from 
a programmers point of view, but not so from the 
point of view of a systems man. In the event that you 
may have missed the obviously sad conclusion—at that 
point, we were not good system-thinking people. Rather 
we were quite competent, but starry-eyed programmers. 
Needless to say, a jolt such as the one I have just de- 
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scribed, made system thinkers out of us in a hurry. The 
striking difference, it seems to me, is that a programmer 
may turn out some very outstanding and elegant work, 
but it’s of little, if any, value unless an affirmative 
answer can be given to these two questions: (1) does it 
“fit”? with other programs? and (2) is it feasible to 
use the peripheral equipment implied by this program? 

Let’s be specific and consider a possible situation. A 
program may be written to handle insurance claims. 
This program may purport to handle such highly useful 
transactions as: post newly incurred claims into a tape 
record, effect changes to existing claim records on tape, 
interrogate existing claim records on tape and pay claim 
benefits when due, and other similar functions. It is 
very likely that such a program would require the exist- 
ence and use of a master policy tape from which this 
claim program would extract certain vital information. 
Well, does such a master policy tape exist? Fortunately, 
this kind of fundamental question is almost always 
recognized early in the game; so, because we’re smart 
persons, let’s say it does exist. Does this tape contain 
all the information required by the claim program? At 
this point we're apt to have a problem. We did at 
Argonaut. If the program output is in the form of 
printed matter, is the program consistent with the 
form? Or, if the form should be revised, who knows 
about it? You may say, “we wouldn’t ever overlook 
things as important as that.” Resist the temptation. I 
said it once. It’s not an easy kind of statement to live 
with. I could take the remainder of my time enumerat- 
ing the things of this sort that we overlooked the first 
time around. If we were starting from scratch, I think 
we might take our very best programmer, relieve him 
of all programming responsibility, and assign him the 
task of analyzing and coordinating all the aspects of 
program interdependability. I’m sure the return would 
be high. 

As to this peripheral equipment. I’m speaking prin- 
cipally of information collection devices such as tape- 
punching typewriters and adding machines. You will 
recall that the question dealt with feasibility of the use 
of this equipment. Frankly, Argonaut has had no real 
problem in this regard. Our input information collec- 
tion requirements are such that the solution is quite 
simple and obvious. However, I can think of a situation 
or two that is not so simple. For example, let’s assume 
that our problem is that of several offices, remote from 
our data processing center, each of which daily receives 
bills that are to be approved for payment against 
claims. This is the kind of situation where the volume 
of items is apt to be high. We'll make it simple and say 
that, if the bill is approved, the data processing center 
can issue a check and perform all necessary information 
posting if it receives such a bare amount of information 
as policy number, claim number, payee number, and 
amount to be paid. Obviously, this is a fine job for an 
adding machine tape punch. A high volume of bills can 
be disposed of in this manner by a single operator in 
a reasonable length of time. However, insurance people 
have an aversion to simple, straightforward solutions 


such as this. For instance, they seem to thrive on alpha- 
betical prefixes and suffixes. Obviously, an add-punch 
will no longer perform our job. If a tape-punching 
typewriter is required, we might just as well type the 
entire check. If that is one, we’ve eliminated the need 
for this very elegant program. Not only that, but we’ve 
imposed heavy accuracy requirements on the typist if a 
by-product information tape is desired. You just don’t 
get best efficiency from tape-punching equipment when 
preparing an end-result document. I think perhaps 
some sort of limited alpha device on add-punches might 
find wide use in the paper shuffling institutions of our 
nation. 

Some of our more interesting and frightening ex- 
periences have occurred in the realm that might be 
termed “getting the word out.” In fact, I’m beginning 
to feel that the armed forces have a pretty good thing 
going in their “Plan of the Day.” Almost two years 
ago, a couple of us at Argonaut devised a master policy 
numbering scheme that would account uniquely for 
every policy for 83 years without a repetition of num- 
bers. This numbering system contained provision for 
100 groupings such as geographical zone, type of busi- 
ness, etc. In spite of the availability of this master num- 
bering system, a memorandum crossed my desk less 
than a week ago, announcing the inauguration of a 
completely foreign system for a new type of policy we 
are about to start using. To add insult to injury this 
new numbering scheme employs the same ten digit 
number we devised and simply adds a digit. Well, any 
fool knows our computer can’t handle an eleven digit 
number! Someone didn’t know. And this person is aw- 
fully close to home. Somehow he just didn’t get the 
word, 

To further illustrate this point in a different man- 
ner, Vl relate some of our debugging experiences. 
When our computing equipment arrived, we had an 
impressive amount of debugging yet to be done. We 
set up a system of time allotment for various persons 
and programs and dug in. One of our more experienced 
men along with the consultants developed procedures 
for debugging that were designed to make the most 
efficient use of time and equipment. After a few weeks, 
we reviewed progress and were not entirely pleased. It 
was soon discovered that there was an almost universal 
disregard for our debugging procedures. Some said they 
didn’t realize the ground rules were official yet. Others 
said they knew about the rules but went ahead doing 
the same old thing because they were not familiar with 
the new methods and simply felt safer taking the old 
road. Here again, the word didn’t get out or, worse yet, 
if it got out, no offer of assistance went with it. It 
seems that everyone in this business is slogan conscious 
these days; not to be left out, we’ve adopted one that 
has some real significance “If all else fails, FOLLOW 
DIRECTIONS.” The aforementioned situation has, of 
course, been corrected; but not without some loss of 
time and attendant cost. Were we in a position to start 
this project over again, we would certainly pay more 
attention to this area. 


70 1957 ELECTRONIC BUSINESS SYSTEMS CONFERENCE 


There is a tendency on the part of many firms to 
justify the acquisition of computing equipment on the 
basis of the savings of a single job to pay for the 
system. I admit that there is merit in this approach; it 
ultimately saves money. However, in order to achieve 
maximum savings, many of these firms will eventually 
expand their systems many fold both in terms of equip- 
ment and scope of work performed. Argonaut, on the 
other hand, by virtue of economic necessity has had to 
include all major parts of its information system, in this 
first effort. I can’t think of a more difficult task than 
that of coordinating the build-up of such an informa- 
tion system to the point of computer production work. 
Neither can I think of a more rewarding task. Perhaps 
the greatest reward to be gained is management accept- 
ance. This point is neatly summed up in an article in a 
recent issue of Computing News which states; “The 
greatest sales talk to management from the computer 
room is a voluminous output of work, correctly and 
rapidly done. With the exception of the pure research 
problem, it is the job of most computer installations to 
crank out the production, and keep cranking it out.” 

I think we’re somewhat fortunate to be in the posi- 
tion of having to convert our entire information system 
at once rather than one job at a time. In spite of the 
chaos that is occasioned by having so many irons in the 
fire at one time, I think that this method, if even half- 
way controlled, is potentially the quickest and most eco- 
nomical way to get the job done. We are firm in this 
approach and would do it again, if faced with the same 
situation. 

Work scheduling has presented problems. Trying to 
schedule production and debugging during the same 
eight hour shift is not always easy. Debugging sessions 
have been kept to a strict hour and half maximum. 
Production runs, on the other hand, don’t always end at 
the scheduled time. This seems to be principally due to 
two things: (1) program stops due to faulty input in- 
formation, and (2) inaccurate timing estimates. Our 
efforts to correct these situations have been fairly suc- 
cessful. Our first effort was to add more pre-input con- 
trols to the system. This implies more card handling 
with, of course, more expense, but the return on this 
investment is in the form of fewer costly job stops. Our 
second effort was a re-evaluation of our original time 
estimates. On the whole, they appeared to be as accur- 
ate as could be expected and we were able to attribute 
any discrepancies to additional input volume due to 
conversion. By this I mean that an average predicted 
workload was increased by picking up some old records, 
etc. In addition, the obvious step of utilizing second 
shift time has been taken. One of the nice things about 
owning a computer, as opposed to leasing, is the free 
use of second and third shift time. 

While we’re on the subject, I may as well explore a 
few of the pros and cons of purchase vs. lease. In our 
case, it was simple; we couldn’t afford to lease. The 
only possible advantage I can think of in leasing is the 
uncertainty of the used computer market four or five 
years from now when we might want to acquire new 


equipment. Actually, we feel that if we ever do want to 
replace our present equipment, there will be any num- 
ber of small companies that will be anxious to purchase 
our equipment at a bargain price. What do we feel are 
the advantages of owning the equipment? Well, cer- 
tainly one of the greatest advantages is this freedom of 
use, I just mentioned. Another distinct advantage is the 
freedom to have your own maintenance engineers. Con- 
trary to popular belief, maintenance, in our case at 
least, is not a headache at all, but quite the opposite. 
Our operating records show a 7 per cent unscheduled 
down time and 23 per cent scheduled maintenance. An- 
other nice feature is that we accomplish this at a savings 
of about 65 per cent as compared to contract mainten- 
ance cost. One of the real payoffs of having our own 
maintenance engineers is one that we hadn’t foreseen at 
all. Programmers always wish they had just one or two 
more commands at their disposal, no matter which 
machine they may be working on. We have found that 
often these desired new commands can be constructed 
without too much effort or redesign. Our maintenance 
staff has added two new commands and we contemplate 
one or two more in the near future. We have also suc- 
cessfully accomplished a modification to our tape sys- 
tem which makes it considerably more useful to us. So 
you see why we feel we made a good decision in buying 
and providing our own maintenance. 


As a summary, I’ll just read this list of items, classi- 
fied as “good” or “goof.” 

On the “good” list we can include: 

1. Consulting services 

2. Overall approach to problems 

3. Decision as to which equipment to get 

4, Purchase, rather than lease 

5. Have our own maintenance personnel 

On the “goof” list, I must include: 

1. Handling of staffing problems 

2. Coordination of programming and overall sys- 

tems effort 

3. Computer scheduling 

I thank you for the opportunity of appearing before 
you and extend a warm invitation to visit our installa- 
tion when you’re in the Bay Area next. 


WORKMEN’S COMPENSATION INSURANCE 


Under the laws of the State of California, every 
employer is considered liable for injuries sustained by 
his employees. In order to make sure that every em- 
ployer is able to meet his obligations in the event of an 
accident, the state requires that employers obtain work- 
men’s compensation insurance. This insurance is offer- 
ed by a number of private insurance carriers, and also 
by the State of California through its State Compensa- 
tion Insurance Fund. Argonaut Insurance at present 
ranks second in premium volume among the private car- 
riers of workmen’s compensation insurance in the state. 

The basic information flow involved in Argonaut’s 
operations are illustrated in Figure 1 which you have. 
The company writes its insurance only through local 
agents and brokers, called collectively “producers.” 
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Producers are independent agents, who are free to 
choose from a number of carriers to write the insurance. 
The producer writes out an application for the pros- 
pective assured and mails or telephones it to one of the 
main offices of the company. There an underwriter re- 
views the application and decides whether or not the 
company wishes to write a policy for the prospective 
assured. If the underwriter approves tHe application, a 
policy is writen for a one-year period. If, at the end 
of that year, the producer and the assured want the 
policy renewed, the underwriter will review the policy 
and its losses and will decide whether to write the 
policy for another year. 


The premium on a workmen’s compensation policy 
is usually computed on the basis of the amount of the 
assured’s payroll. At various times during the year the 
assured is requested to report to the company the 
amount of his payroll by type of work done. Payroll 
auditors at the main office of the company review these 
payroll reports and determine the amount of the prem- 
ium due. An invoice is then sent to the producer, who 
must in turn collect the premiums from the assured. 
The company has a Collections Department which keeps 
track of these payments due and makes sure that they 
are received from the producer. 


If an employee of an assured is injured, he is sent 
by his employer to one of the doctors designated by the 


company. Both the employer and the doctor send a 
report of the injury to the Claims Deparmtent in one 
of the two main offices of the company. There, a claim 
examiner inspects the report to make sure that the in- 
jured employee is covered by a policy written by the 
company. If the claimant is covered, the company will 
pay all of his medical bills and send him weekly com- 
pensation checks for wages lost after the first week of 
temporary disability. If the claimant is determined to 
be permanently disabled, he will continue to receive 
payment during a period of readjustment, even if he is 
able to work again. If the claimant’s permanent dis- 
ability is major, payments may continue for the remain- 
der of his life. 

Argonaut Underwriters, Inc., operate the company 
for the benefit of the policy holders, in return for a 
fee based on gross premium volume. Profits which re- 
main after payment of this fee and after payment of 
losses are the property of the policy holders and are re- 
turned each year in the form of dividends. The percent 
of premium returned as dividend for each policy is 
based on the cost of handling the policy, as reflected 
in earned premium, and on the amount paid out in 
claims on the policy. 

This simplified description of the operations of the 
company touches only on the standard processing of an 
average policy. 


